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© Secure messaging systems. 

© In a secure messaging system with several terminals 10, 10A t etc, 12 there are many system (control) 
messages, between the various terminals; these are liable to deliberate or accidental change of sequence, 
deletion, duplication, etc. To protect the system against this, an acknowledgement is sent for every message 
received (except a simple acknowledgement), and each station stores copies of the messages it has sent, 
deleting them only when acknowledged. When a new message is to be sent or a non-receipt of acknowledge- 
ment time-out occurs, a packet is sent with ail previous messages in store prefixed to the new message, so the 
receiving station cannot act on the new message before receiving and acting on the previous messages. (There 
are known means for ignoring duplicated messages). Preferably there is chained serial authentication of the 
messages in the packet so that even if one is garbled, they can be acted on up to that point. For security and 
other reasons, user messages are in general not treated similarly but sent only once; with these, error control is 
a user responsibility. 
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SECURE MESSAGING SYSTEMS 



The present invention relates to secure mess aging systems , computers are 

Communication networks in which a co ns.derabl , number o * whjc P h ^ not secure , such 

interconnected are weli known. Such systems ^^^^Zf^ (eavesdropping) and active 

which includes a substantial number of terminals. errors . T he system comprises a substantial 

The present invention relates more specially to message ^ * h@r Qver an insecure 

f0 number of terminals and a key distri bution ^^^"jST^m self-evidently involves the 
medium such as a public ^^^^ ST.S^naBon generated by the users of the 
passage of user messages; that is. messages wh.cn ca y ri| invo | ves the passage of 

terminals and which pass between the Maintain ./in good operational order 

system messages; that is, messages wh.ch support the system , a messages are those involved in 

JS i do not themselves carry "-^^J^^.'S in updlg keys). 

setting up a link between two user agents (UA s . ^ ™* ls ; a * e to upderg0 accide ntal or deliberate 
All messages, both user messages and systerr SQ that it cannot be 
interference. Accidental • interference may involve ^com*™^ transmission means; its 
recognized; the deletion of a message, by l^^,?"^ sequence of messages by the 
20 duplication by the transmission means; or the mte .changing ot t q involve the interception and 
transmission means. Deiiberate i^erence wou ^ d be of b y^ J messages and their retransmission in a 

earlier message. Certain other messages ^ .not ong,na*ng me ssage , ^ ^ g ijnk ^ 

response to a preceding message; for example one termma y ^ ^ ^ may 

30 another terminal, and that involves the generat.cn of a message back to .^.^ by 

be, between two locations in the network, sequences of ^"'^^^Vmore than one message 
an originating message and being one ^rV'^X^^owW^ment of the previous message, 
long, then each message after the first obv.ously J^*^"^^ ° a conventional technique wherein 
as well as carrying some information of its ^^^eVZ^ge^ message, which acknowl- 

35 all such sequences are «"^^ b^ carr is^ot other information. The present system a.so 

:r^v^^ — - * ^ — 

40 ^SrSlo one aspect of the present ^J^J^ZJ^^ 

terminal, all system messages (except simple aCknovrtodgj^ ap wh@n ^ 

deletes those messages from the store when ^'J^^ in which all stored 

terminal has to send a fresh message to t ^ [ ^'^^^TSThe'resh massage. 

45 messages for that terminal are included n their correct order n g message becomes 

This technique may be used for all mess .gee. £™ y rQq ^ sting the setting up of a link 
redundant as a result of a later message. For example ""W^J" 8 preferab|y 
becomes redundant if a later message ,s sent ^"J^^^,^ sin ce there is no longer any 

has been received. macei)n , <? _ rp eve ntualiv received, since any which have not 
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' acted upon in strictly the correct order, because whenever the sending terminal sends a fresh message, it 
precedes it with a copy of all previously unacknowledged non-redundant messages in the correct order in a 
single packet. Thus whenever a message is received, all previous non-redundant messages whose previous 
reception is doubtful are received again. Of course, it may be that some of those messages had already 
5 been received, but their acknowledgements had gone astray or are still in transit. Thus some messages 
may be received more than once; but that is dealt with by the conventional technique for ignoring 
repetitions (keeping a record of the message numbers of received messages). It may be noted that only the 
message number of the last message received need be recorded, because the present system ensures that 
messages cannot be received out of their correct sequence. 
70 The packet must of course be sent in such a way that corruption, whether accidental or malicious, is 
detected. Conventional techniques for this are well known; in the present system, this is achieved by means 
of a message authentication code (MAC). The system preferably assembles the packets in such a form that 
if a packet is damaged, messages preceding the point of damage can be acted on by the receiving 
terminal. Thus the receiving terminal is able to bring itself part way up to date even if the trailing end of the 
75 packet is lost. The messages in the packet which are received are of course acknowledged, either by 
simple acknowledgement or by further messages. Simple acknowledgements are sent only once, as noted 
above; further messages are sent one by one, being stored in the store and any unacknowledged ones 
being added to the front of packets as described. 

To assemble a packet in such a way that messages preceding a point of damage to the packet can be 
20 acted upon, a MAC is calculated for each message, and the MAC for each message is included in the body 
of the next message. This also ensures that the messages in a packet cannot be tampered with, by 
removal, insertion, or re-ordering of messages, as any such tampering would result in a failure of the MAC 
checking at the point in the packet where the tampering occurred. 

User messages are dealt with in a different way by the present system. A user message is sent only 
25 once by the system, and it is in general up to the users to devise their own measures for determining 
whether such messages are received, and in the correct order. Preferably however the system permits a 
user to include an acknowledgement request in a user message, so that the receiving terminal automatically 
returns a system acknowledgement message to the user on receiving such a message. Optionally, each 
terminal may maintain a log of the user messages received, so that it can identify and reject duplicate 
30 messages. The user may then be able to inspect the log to discover whether any messages in the 
sequence are missing; it will then be up to the user to decide what action to take, eg sending a user 
message to the other terminal telling that user there that some of his messages have not been received. 
Optionally, the system may automatically acknowledge all user messages, with the sending terminal also 
maintaining a similar log of acknowledgements received, so that the user can inspect this to discover 
35 whether any messages in the sequences have not been acknowledged; it is then up to the user to decide 
what action to take, eg resending a message to the other terminal, or sending a user message to the other 
terminal asking whether an earlier message was in fact received. 

A secure messaging system embodying the invention will now be described, by way of example, with 
reference to the drawings, in which: 
40 Fig. 1 is a block diagram of the system; 

Fig. 2 is a block diagram of part of a User Agent (UA) terminal; 
Fig. 3 is a block diagram of the Key Distribution Centre (KDC); 
Fig. 4 is a- more general block diagram of a UA terminal; 
Fig. 4A is a detailed block diagram of a part of the KDC; and 
45 Fig. 5 is a more detailed block diagram of a part of the KDC; and 

Fig. 6 is a more detailed block diagram of a further part of a UA terminal. 
The description is divided into the following sections: 

General system arrangement - Fig. 1 
so General system operation - key hierarchy 

Message structure and UA structure 

UA to KDC linkage 

Communication between UA's 

System message error recovery 
55 Local message storage 

Change of UA 

KDC message togging 
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,t should be noted that other aspects of this system are described and claimed in two copending 
applications filed simultaneously herewith. 

General system arrangement - Fig, j 

0,9 S^T^STie is shown as being tad by a eontro, lin. from .he PC ,4. tar contfo, purpose^ 

' ooXn concerned wS> the nar data passing ta and from ». security module. (AIM. of course. 0» 
PC «, y Tmlnica^ directly with .he medium ,1 for sending and receiving 

The security modules 16 and 17 are constructed using known tachn,ques Thus each module .ncludes 

^^S^ to varying delays so that their order may be changed, and dupi.cat.ng ( echeng ) 
messages. inte rce P tion and possible physical attack on the security module as noted 

to have passed control, so that a password can be entered by the rightful user. w,th the module then on.y 
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responding to that password. If the user knows how long his absence will be, a time lock may be used; the 
internal battery of the module ensures that this will run continuously. The password may also be generated 
by the module and fed out to a floppy disc which can be physically removed and retained by the rightful 
user. 

5 Slightly different protection techniques may of course be used for the security modules of the user 
terminals and that of the key distribution centre, since the KDC is likely to be less vulnerable to attack than 
a user terminal, while on the other hand a successful attack against the KDC would be much more 
damaging that one against a user terminal. 

w 

General system operation - key hierarchy 

The operation of the present system is controlled by the KDC 12 at two levels. First, each UA is 
assigned a unique User Master Key (UMK) by the KDC; this UMK is taken to the UA over the non-electronic 

is channel 13 and installed at the UA (in the security module 16), eg by a member of the staff operating the 
KDC. This key is thereafter used to establish or verify messages between the UA and the KDC. Second, if a 
UA wants to communicate with another UA, then the KDC must be used to set up a secure channel 
between the two UA's. The UA requesting the link informs the KDC, which accordingly sets up the link, but 
thereafter participates in the use of the link only at infrequent intervals (when an LMK needs updating). 

20 There is also a third level of operation of the system, relating to the secure storage of information at a 
single UA; this operation does not involve the KDC. 

The physical locations and the keys and their hierarchy, and the abbreviations used, are given in Table 
I. The message key is not shown as being in the hierarchy, because every message is encrypted under a 
different message key, generated solely for that message, whatever level of the hierarchy is involved for 

25 that message. In fact, every message is encrypted by using a pair of keys: one key, termed the base key, 
is a key taken from the hierarchy, and the other is the message key for that message. 



Table I 

30 

Physical locations KDC - Key Distribution Centre 
UA - User Agent (terminal or node) 



35 Keys UMK - User Master Key 
(KDC <-> UA) 

CKD - Control Data Key MK - Message Key 
(UA <-> UA) 

LMK - Link Master Key 
40 LDK - Link Data Key MK - Message Key 
(UA internal) 

PMK - Personal Master Key 

PSMK - Personal Sub-Master Key 

PDK - Personal Data Key MK - Message Key 



If an outsider can accumulate enough messages encoded with the same key, he may eventually be 
able to break the system and recover the key. The keys are therefore changed at suitable intervals for this 

so reason, and also so that if an outsider should, somehow acquire a key, that will eventually become useless 
to him as a result of such key updating. However, the UMK's are distributed physically, and changes to 
them are therefore difficult to achieve. A hierarchical system of keys is therefore used, in which each key is 
changed repeatedly before any change is made to the key above it in the hierarchy. The superior key can 
be used to transmit information concerning the changes of a lower key. The KDC therefore only becomes 

55 involved in key changes involving the physical transport of keys (new UMK's) at relatively infrequent 
intervals, so that such updating does not become unduly burdensome. 



5 
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Message structure and UA stmcture 

The various UA's and the KDC communicate with each other by means of mjMgjj. The- messages 
ail have broadly the same structure, though there are — as ^ «« * ^°J d ^ Qp by the 
messages is into system messages ^J^^J^JZ^^ to users and contain 
system without the knowledge of the user, f^J^T £>« and there are several different types; 

ssc r= z M£ ^ ^ * * tarsus. 

replaced by a new key). r( , anri p r 4 a ff Pr sufficient usage, by the physical transport 

- The UMK, while relatively permanent, can be change date US ^ * ed Y which is initially set to 

a^S^ - can be set from the 

a CDK register 34, with an associated usage counter • 3 ^^^^J^^ 

from a random signal generator 36, which CDK so generated is promptly 

or a radioactive decay counter, to ensure that the key is truly ^random ^ gene rator S generate 

( it contains a key in clear (ie not protected by encrypdo n) assem bly register 37 with several 

Considering the messages in more deta... the UA indud " * ™^~™,J B ^ a of the message 
sections, in which messages (including the present one) are m"™ 1 *- ™ J" , meaning " 0 r "data" (if 
assembly register 37 is a message body or ^ «^n. »d J ^ed I conta^ the mea ^ ^ ^ 
any) of the message. The message assembly reg.ster 37 has . at its left nana e . erejn 

B secL SC and a destination section ON. The source secfcon ^^^^SSnatlon fed into it. 
representing the UA, while the desfnat.cn section ^'^^J^ KN is a key number and 
The next section MT is a message type area de «nbedWow. ^ , s J ed t0 contain 
message identifier section described ^^^^^XTn^ authentication code area 

, Z^^^^^^^ * - — can b * disre9ard8d (or taken 

- Tm^type format st^earea J^J^W 
such as the message to the KDC that a CDK is being sent ana mm k messages to the 

area is selected and passed ^^f^Z ™«^Zo< messages (user or system) to 
30 KDC, this storage area also holds the KDC d "t.nation communication with another 

another UA, the destination code of the receding UA mus be P^"^ jned b {he user this CO de 

unit 43 discussed below. f th key hierarchy and a 
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message which identified the base key used for the message and also acts as a message number which 
uniquely identifies the message. This message number is obtained by concatenating the key numbers of 
the keys down the hierarchy to the base key, together with the usage count of the base key. Each key 
register has an associated key number store, 40A for the UMK in register 32 and 33A for the CDK in 

5 register 34. Thus if the base key is a UMK, the contents of register 40A and counter 40 are used, while if 
the base key is a CDK, the contents of registers 40A, 33 and of counter 33 are used. Each key number is 
incremented by 1 each time the associated key is changed. Hence for a given message type, the message 
numbers are in strictly ascending order, because the key numbers for each key are normally rising, and 
when such a number fails, by being reset to 0 ( that is as a result of the next number up the sequence 

w being incremented. The branch of the hierarchy involved and the distance down the hierarchy will be 
identified by the message type; for example, for the message type "CDK being passed to KDC being 
considered here, the key hierarchy necessarily involved only the UMK. 

It should be noted that although the key number of a key is similar to the usage count of the next key 
up the hierarchy, the two will not necessarily be identical. This is because in some circumstances a higher 

75 key in the hierarchy can be used, and so increasing its usage count, without the next key down being 
changed. To avoid such problems, the usage counts and key numbers are therefore maintained distinct 
throughout the system. (This also means that the message numbers are not necessarily sequential). 

(This system depends to some extent on the MT contents indicating the message type in clear. It could 
of course be modified, eg by including the MT contents as part of what is encrypted; the length of the 

20 message identifier (ie the key number) or, what is the equivalent, the level of the key in the hierarchy, would 
then have to be indicated separately). 

In general, the body of each message is encrypted using a unique key for that message, the message 
key MK. This message key is generated by the UA by means of the random key generator RND 36, and 
fed into a message key register MK 39. 

25 It is assumed that the cryptographic system used is one in which the same key is used for encryption 
and decryption, such as the DES/DEA standard or something similar. (It would be possible to use a system 
with different encryption and decryption keys, such as a "public key" system, but that would require both 
keys of a key pair to be stored, and the appropriate one to be used for encryption and decryption). The 
encryption technique used is CBC (Cipher Block Chaining), which requires an initialization vector IV and an 

30 encryption key. (This is described for example in ANSI standard X3.1 06-1 983 Modes of Operation of the 
DEA). An initialization vector IV is first generated by encrypting the message key MK under the base key. 
An encryption key for the message is then obtained by encrypting the IV again under the base key. Since 
the message key MK is sent in clear and the receiver has a copy of the base key, the message can be 
decrypted at the other end, by encrypting the rnessage key under the base key to yield the initialization 

35 vector and again to yield the decryption key; the IV and decryption key are then used to decrypt the 
message. The use of a different MK for each message means that if a message is repeated in almost the 
same form (eg the same user message being sent a second time with perhaps only a time change), it will 
be encrypted under a different key, so an outsider will not be able to gain much assistance from the 
repetition in trying to breach the encryption. 

40 After a message is encrypted, the contents of the MT, KN, MK, PMAC, and MB sections of the 
message assembly register 39 are passed to a Message Authentication Code calculating unit MAC 42, in 
which a MAC value is calculated, and that value is passed back to the MAC section of the message 
assembly register 37. The MAC value is thus included as part of the message. The MAC is calculated by 
an encryption-like process ("MAC-ciphering") using the CBC technique. The final block resulting from this 

45 process forms the MAC. The "MAC-ciphering" is done using a key and an initialization vector (IV); the key 
(the "MAC-cipher-key") is obtained as a fixed function of the base key used for encrypting the. message, 
and the IV is taken as zero. The source code and destination code do not need to be authenticated, 
because if either is altered in any way, the unit which actually receives the message - a UA or the KDC - 
will be unable to authenticate the message, because it will not be using the proper key in attempting 

so authentication by the MAC check. 

The encryption/decryption unit 41 and the MAC generator 42 must be inside the security module, 
because they have to receive keys in clear. Similarly, the UMK register 32 must be inside the security 
module , because it contains a key in clear. While it would be possible to store other keys outside the 
module, encrypted under the UMK and being decrypted in the module when required, it is much more 

55 convenient to store all keys in clear in registers inside the module. The message assembly register 37 is 
also of course inside the module, to keep the message inviolate before it is encrypted and authenticated. 

Each message sent or received is passed through an interface unit 43 which performs any lower level 
protocol processing which may be required to interface with the transmission medium 11. In particular, the 
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interf ace unit 43 may be a maHbo* ^^^^^X^^ 5 ^^ 
mailboxes, one for system messages and the o ^ J m terminals not forming part of 

r^na^^^^ - is — imp,emented by means of 

5 ^ SSI tHe receiving ci^trv t ? renter 37 <^^^Z7^^ 
received from the medium 11 via the interface unit 43 l The message ^num 

inspected to check that the corresponding base key £ message identifier KN as 

by means of the MAC generator un.t 42 . using the base key ^ id ™ 5 {in section MAC) 

T0 the "Mac-ciphering" key. The resulting MAC ^pared w,th the MAC ^ of the mes g , ^ 
by a comparator 44. If the computed MAC ^J^r^^^J^J^Z kind In it (perhaps 

which is unknown by th<= , outsider ^ tQ check ^ ^ message is t a 

The message number KN ot trte message k „ ha ^ 0 H tn see if the message number is 

repetition of one that has been received prevous.y. It can be chewed ^see^ * missing 
reasonable, having regard to the message numbers ^^^^^^ at length later). 
20 messages, duplicated message body section MB is not 
If the message passes the KN and MAC ^ < ^ sectjon „ encrypted under the base 

empty) the message is decrypted. For this, the message Kev ' n " b s {h |V and this is 

key identified by the message number) using the ™ c ?^%Xan6 SJrftoo Key for decrypting 
encrypted again under the base key to obta,n the ^^^^^^^^S «• ^ ^ int0 

r^SlcknolW-nt messages, have 3-d this is acted on by the 

The contents of the MB sect.on are then a system message ^o som ej cQntajn & 

control circuitry 30. Sti.l assuming ^^^^^^^J^ raster 47. y There is a pair 
30 CDK key. If so. then that rece.ved key is fed into a COW ^J* 46 £ a g ^ & 

of received CDK registers because when a change of CDK , n the KD ^ °^ ^ recei ved CDK 

using the previous CDK to be received after the new ^.^.^^i^ the MB section) feed 

be something else radically wrong if a discarded CDK is needed). 



40 UA to KDC linkage 



45 



50 



55 



The system starts with the UMK's (User Master Keys) d^b ^ ^Sg ^^UMk" 
agents), but with no other keys existing and with no corr.mun.ca^on hnks ^.stmg^ ^ =oon 
installed in the UA. a linkage must be established between J^J^^o ^Ige is constructed 
key CDK is generated and stored in the UA in the JDK register 34. and la -^J^ UMK. The KDC 

Thus the link between the UA and the KDC is established w.tn a p CDK received 

end of the link uses the CDK which it generated to ^* ^^HriS £ This use of pairs of 

from the other end to decrypt further messages receded from the U/Vs 

LeTs for the two directions in which messages can pass occurs also w.th links betwee in UA * 

^ The acknowledgement by the KDC of the receipt of the ^^^ C ^^ "om the 

Sc^ ^C^r T^gH ^ .5£S3 S r UA. Thus the exchange of 
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CDK's may be achieved by 3 messages; the CDK from the UA to the KDC; the acknowledgement of receipt 
with the CDK from the KDC to the UA; and the acknowledgement from the UA to the KDC. 

The link between the UA and the KDC is thus bidirectional, with a distinct CDK for each direction. Once 
the link between the UA and the KDC has been established in this way, almost all further messages 

5 between the two units are by means of the CDK's as base keys. When the usage of a CDK exceeds the 
preset limit, a fresh CDK is generated, and transmitted under encryption by the UMK as described above. 
Since the message flow between the UA and the KDC is relatively low, this hierarchy of 2 levels (UMK and 
CDK) is sufficient to enable the system to run for a time which requires changes to UMK's only rarely. In 
fact, the usage of UMK f s is dependent also on certain communications between UA's, when the new LMK's 

70 are required, as will be seen below. Messages between the UA and the KDC are required in general only 
when a user (UA) wishes to establish or break a link with another user (UA), which will occur only rarely (as 
links are regarded as substantially permanent), and for updating LMK's. 

In general.the number of messages (whether user or system) flowing in the two directions over a link 
need not be the same; subsequent updates of fresh CDK's will therefore involve the updating of only a 

75 single CDK for the link, which will involve the sending of the new CDK one way and the sending of an 
acknowledgement message the other way. 

If required, the KDC can be programmed, when the system is first set up to all links initially required. 
This involves storing in the unit 31 (Fig.2) for each UA a considerable number of system messages, which 
thus do not require encryption (because they are transported with the UMK's and their security is physical, 

20 like that of the UMK's), which would otherwise have to be sent between the KDC and the various UA's when 
the system first became operational. This would markedly reduce the initial quantity of system messages 
involving the KDC. The structure of the KDC is similar to that of the UA, and is shown in block form in Fig. 
3. There is a control unit 50 (corresponding to control unit 30 of the UA shown in Fig. 2) and single 
message assembly and processing circuitry 51 , which includes a message assembly register 52 

25 (corresponding to register 37); the associated circuitry of encryption/decryption unit, MAC generator, and 
MAC comparator are regarded here as part of the message assembly and processing circuitry 51 and so 
not shown separately. The KDC has a separate set of key registers and usage counters for each UA; these 
are shown as blocks 53, 54, 55, ... for the keys used by the KDC for sending (ie corresponding to the 
registers 32, 34, and 39 and associated usage counters and key number registers), and for the keys used 

30 by the UA's for sending messages to the KDC (ie corresponding to the registers 46 and 47 and associated 
registers 48 and 49). The blocks 53, 54,55, ... are multiplexed to the message assembly and processing 
circuitry 51 by a multiplexer 60 which is controlled by a selector circuit 61. The contents of the selector 
circuit 61 select the appropriate one of blocks 53, 54, 55, ... for obtaining the keys for dealing with received 
messages and preparing messages to be sent out. Thus when a message is received, the selector circuit 

35 61 is filled with the contents of the SC section of the register 52, this section containing the source code of 
the received message and thus identifying which UA the message has come from, if a reply message is to 
be sent back to the UA which sent the received message, the selector contents are left unchanged, so that 
the appropriate one of blocks 53, 54, 55, ... remains selected for the preparation of the reply message. If 
however a message is to be sent out to a different UA, then the contents of the selector circuit 61 must of 

40 course be changed accordingly. This may happen, for example, when a link is being established. The 
message from UA1 to the KDC requesting the establishment of the link contains, in its MB portion, the code 
for UA2, and this code must be transferred to the selector circuit 61 for sending the appropriate message to 
UA2. The two codes are in this case used in alternation by the selector circuit 61, as messages are 
received from and sent to UA1 and UA2. 

45 

Communication between UA's 



For communication to be possible, links must be set up between pairs of UA's. Each such link is set up 
so by a UA requesting the KDC to set up a link between it and another specified UA. The KDC then sets up 
the requested link, provided that neither of the UA's which will be involved in the link exceeds an upper limit 
on how many links it can have with other UA's, and that the UA on the "receiving" end of the requested link 
does not refuse to accept the link. Once the link has been set up, it is symmetric in that the UA's at the two 
ends are on an equal footing; either can transmit to the other, or decide to break the link. 
55 The process of setting up the link is summarized by Table IIA, where the UA requesting the link is 
called UA1 and the UA with which UA1 wants a link is called UA2: 
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Table IIA 

UA1 > KDC: UA1 asks the KDC for a link to UA2 

UA2 <— KDC: KDC sends transmitting and receiving LMK' s to 
UA2 

UA2 > KDC: UA2 acknowledges receipt 

UAL < KDC: KDC sends the keys to UA1 

" ln mor e detai,, when the user of UAl -™ ^ ™ s^S^Z 
the user of UA1, UA1 sends a system message to the KDC This ^ m 9 t0 the KDC 

as base key the CDK key of UA1, which ,, the toj < ^J" ™ indicates that UA1 is 

(except, of course, for system messages .nvolv.ng p DK "P^ 1 "^ ™ ^aI On receiving this message, 

« asking for a link to be set up. and ^ -essage body ^^^^^^ J> asking UA2 if 
the KDC generates a random pa.r of LMK s, and sen* a ^ J e " Qf UA1 and tne ^ L MK's. all 

it wants to accept a link with UA1 anc the , me« ^^^2,^ the KDC to UA2. When UA2 
encrypted using as base key the CDK used for sena,n 9 y . k |f the link is accepted, a 

receives this message, its user has to dec.de whether or ™* to acc ^ \™.^ u6ing the code of UA1 (to 

20 message is sent from UA2 to the KDC ind.cat.ng ac ce^ance re S to further UA's). and 

distinguish that acceptance message from any l.nk setting "P r "^ eS ^ ^ KDC . The KDC. on 
encrypted using as base key the CDK used ^.^^^^^ mk by UA2, and including 

" ^ re™s is that the two UA's. UA1 and UA2, now have a shared pair of LMK's which they can 

use to communicate with each other directly. ach ieved As a practical matter, the UA's 

There are certain circumstances ,n wh.ch a I nk may not b e ™ed p 
are provided with only a limited capacity for ma.n am.ng such hnks Hence U A y & 

30 possible number of links, it will refuse to attempt to set ^ Als0 , St* may already 
an existing link so as to create the capacty for h.s " A *™^^£™^ indicating thus, and the 
have the maximum number of links; .t then returns » link has been refused. (If 

KDC in turn sends a system message to UA1 ^^^^^^^ so that its user has the 
desired. UA2 may be arranged to indicate to rts user that ;UM has requested a 

35 option of breaking an existing link to create the capac.t Vj^^^CSid «nk is to be accepted, 
as noted above, if UA2 has such capacty, f "Sem messa9 e indicating the faCt SUCh 

and if the user refuse, the ^ MjQjjn send t £ j^^^^ t0 UA1 indicating what has 

system ™^°J£™ M ^HhL be formed that the requested link has been refused, (.t ,s usual ,n 
happened, and the user of uai mu uius re{usa , (S g|ven) . 

40 secure systems that when a user request has been refused no tne messag e assembly and 

Fig. 4 shows the layout of a UA in ess d e a, J th an show „^nFj2. assemb 0 ^ ^ 

processing circuitry is shown asbtock ^J^ 9 ^ are several blocks of key registers and 
encrypting/decrypting unit 41, and the MAC gene at or ^ » n e e thejr assodated 

associated circuitry. Block 70 conta,ns the ^^l^Z " c0 9 ntain similar key registers 

45 counters, all concerned with commun.cat.on w.th the KDC. B Jock s 71 . u these 
and counters, but each block is concerned with relates to. These 

blocks contains a UA address code register ^^^^^^^ is granted links with them 
registers are filled with the UA address codes as the user of he UA ^*s* m g ^ 
and as they request and are granted .inks with the ' PJ™^ 7»J ^y ccnlroHed by the SC section of 

50 multiplexer 74. In the case of block 70, for the KDC, the setect on ^^ ^^ ^ the selection 
the message assemb.y register 37 or the control "^^^Z^yiB in the SC section of the 
(in response to incoming messages) ,s ^ ^„TIansml«»d messages, selection 

s^s^^ k - lmk and ldk ' and ^ of each 
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level of the receiving keys - in this case, LDK1 and LDK2. Because the lower level key LDK changes 
relatively infrequently, once every say 50 messages, it is unnecessary to keep more than the current and 
immediately previous versions; and because the higher level key LMK changes, even though infrequently, it 
is necessary to keep the previous version as well as the current one, to cater for the times when it has just 
changed. 

Once the link has been set up, user messages can be sent from UA1 to UA2 and vice versa. Although 
the link must obviously be set up in response to a request by a single UA, it is symmetrical once it has 
been set up. To send a user message, the process is broadly similar to the sending of a system message. 
However, the message body section MB of register 37 is of only limited length. A selector switch 76 is 
included in the connection from the MB section of register 37 to the encryption/decryption unit 41, and for 
user messages, the body of the message is fed into the unit 41 as successive 64-bit blocks from the PC 14 
instead of from the register section MB, and the encrypted message is fed back block by block to the PC 
14 (which at this point is acting as the interface unit 43). The MAC of the messages is then calculated and 
fed into the MAC section of register 37. The message length may be indicated either by a length value 
included as part of, say, the MT section, or as the first part of the message body. 

The MAC unit 42 may be arranged to operate at the same time as the encryption, so that before the 
encryption of the message body starts, it has fed into it the contents of those sections of register 37 to the 
left of the MB section, and then as the encrypted message body fed into it, block by block, as it emerges 
from the unit 41. This makes the final MAC available immediately after the last encrypted block of the 
message body. However, the calculation of the MAC in fact involves a process identical to encryption, so it 
is preferably done in practice by using the encrypting/decrypting unit 41 (so that the MAC unit 42 does not 
■ exist as a unit physically distinct from the unit 41 , though of course its logical function remains distinct). In 
this case, of course, the MAC cannot be calculated in parallel with the encryption, and must be calculated 
after the encryption. 

When a user message is received, a special user message acknowledging receipt is generated 
automatically and returned to the sending UA if the sender requests it; such a request is indicated by an 
appropriate message type MT. 

Because the medium 1 1 is unreliable, it is necessary to make provisions for the possible loss of a 
message, reversal of the order of two messages, and duplication of a message by the medium 11. These 
provisions differ for user and system messages; the provisions for user messages will be discussed here. It 
is of course impossible to detect the fact that a message is missing until a later message is received. 

These provisions consist primarily of a pair of bit registers (bit maps) 77 and 78 associated with the two 
received LDK registers LDK1 79 and LDK2 80. Each of the blocks 71, 72, ... contains a respective set of 
these registers; the set for block 71 is shown in Fig. 4A. Each of the registers 77 and 78 has a length, in 
bits, equal to the count at which the LDK key counter in the corresponding sending UA is reset to O. As 
each user message is received, the bit corresponding to the usage count of the LDK of the sending UA 
(which is part of the message number KN) is set. If the bit for a received message is already set that 
indicates that the message has already been received; hence the current version is a duplicate and is 
discarded by the system. 

No system action is normally taken if a user message is not received. In fact, the system does not allow 
missing user messages to be identified, because the message numbers are not necessarily sequential, so a 
clear bit preceding a set bit may mean that there is no user message with that number rather than that a 
user message has not yet been received. 

The system could be modified so that the absence of a user message can be identified once the next 
message is received. This could be done, for example, by giving the user messages strictly sequential 
numbers as well as the existing message numbers, or by including in each user message the message 
number of the preceding user message. But even if this is done, it is preferable to leave the user to decide 
what action to take when he finds that a message has not been received. It may be for example that an 
apparently missing message has been merely delayed rather than lost, and is still en route in the system. 
The user can choose either to leave things as they are or to send a user message of his own to the user of 
the other UA asking for a retransmission of the missing message. Such retransmission will be performed as 
a transmission of an entirely fresh user message as far as the system is concerned; it is up to the sending 
user to include an indication that the new message is in fact a repeat of a previously sent but lost message. 

As stated above, the receipt of a user message may trigger the sending of an acknowledgement 
message which is automatically generated by the system as a special kind of user message. Optionally, 
therefore, the UA's may be arranged to keep a record of such messages sent, the record being updated 
when acknowledgements of receipt are returned. This can be achieved by means of bit maps in which bits 
are only set for messages the message type of which specifies automatic acknowledgement, or by keeping 



11 



0 281 223 



. ,o 9 - the -sage numbers of ^ ^^^^1 S =^«^f« 
messages requiring acknowledgement mean that the original message d,d not 
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reach the intended destination; *W m ™£%% "d elta as a matter of courtesy and good pract.ee. 
destination. It is therefore expected of the use _ » Qf & prevjous messag9 . 
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sequences between the two UA's and the KDC. Two 
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T hta ,,b UA1 > KDC: UA1 asks the KDC for a link to UA2 

^ U J<-k£ C :KDC asks UA2 if it will accept a link with UA1 

UA2->KDC:UA2 acknowledges and agrees 
UA1 V UA2<-KDC:KDC sends receiving keys to UA1 and UA2 
IJA1 & UA2->KDC:UA1 and UA2 acknowledge rece,pt 
UA1 & u£UdC:KDC sends sending keys to UA1 and UA2 

t»Wp IIC UA1 > KDC: UA1 asks the KDC for a link to UA2 

iA & U^-KDC:KDC sends receiving keys to UA1 and U/S 

UA & UA2->KDC:UA1 and UA2 acknowledge rece,pt and UA2 accepts 

UA1 t UA2<-KDC:KDC sends sending keys to UA1 and UA2 
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necessary key to receive that message. messaae until UA2 has received the sending key of 

With the sequence of Tab.e HA, UA cannot send a message unt ^ ^ sQ ^ 

UA1, but UA2 obtains its ^f^^^ ^uisite key to decrypt it. This situation can only 
could transmit a message to UA ^^^^^Jhen "hat UA1. which has requested the link, w.l. f.rst 
arise when the link is initially set up. It is probata e , *er ^ befQre yA1 has reC8lved 

want to send a message. But it cou. d happen hat UA2 nes to e ^ ^ ^ recogni2e 

the key for decrypting it. The result w.ll be ' *«*^^J to decrypt the message. One option here ,s to 
the message number that it does no have the toy ™ e ^° e5S ^ e \ a syste m message, action » taken 
simply reject the message, so that ,t Xba dealt with as discussed above, with the sending 

as discussed later; if it is a user message, th.s wiil b ae ^ ^ 0ptlonally , the 

probably being left to his own resources oi % e keys to decrypt them. 

UA's could be arranged to store such ^essages to awart the rec P ^ ^ confj(jent ^ he „ 

After a link has been established, a UA mar «**to tormm ^ jf he ^ tQ establish 

have no further need to communicate w.th ^ U * * UA will accomm0 date. so that he can 

, another link and already has the max.mum ^^^f ™ ac ^ e this. UA1 deletes from itself all 
only make room for the ^^^^^^^ message to the KDC The KDC logs th.s 
information relating to the link and sends a l.nk ^rnmatrng y inform ation relating to the l.nk. 

and sends a system message to UA2 mstr uctmg tQ a link which doeS not exist. (Such an 

The KDC logs a link deletion as an »™ * ^JJJ te mination of the link at the same time, as one 
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System message error recovery 

As noted above, messages may become "lost" in various ways and may also become duplicated 
(either by a quirk of the medium 11 or by being recorded and deliberately replayed by an outsider). For 

5 user messages, the way in which such events are dealt with has been described above; for system 
messages, the way in which such events are dealt with will now be described. 

With system messages, it is essential that none are lost and that they are dealt with in the correct 
order. For each link of the UA (ie the permanent link to the KDC and each link to another UA), all system 
messages (apart from simple acknowledgements) sent out on that link are stored. They are deleted from 

w the store in two circumstances: when acknowledgement messages for them are received, or if they become 
redundant Each time a new system message is sent, a message packet is prepared in which all the 
previous system messages in the store are included, in the proper order, with the new system message 
being the last in the packet. Thus each time a new system message is generated, all old system messages 
which are unacknowledged and non-redundant are added to its front end, and all the messages - the old 

15 ones plus the new one - are sent as a packet. So the receiver will receive a fresh set of all unacknowledged 
system messages, in the right order, every time a fresh system message is generated. It follows that the 
receiver necessarily acts on system messages in the correct order, because any message is preceded by 
all previous unacknowledged and non-redundant messages in the proper order. Of course, the receiver may 
by then have received an earlier packet of some of these system messages, which it will already have 

20 acted on. The receiver keeps, for each link, a record (by message number) of the last message which it has 
acted on, so it will ignore all duplicate messages, including in particular all such messages in the current 
packet; it will start to respond to those in the current packet as soon as fresh ones are reached. 

An acknowledgement message may be a simple acknowledgement message which does nothing more 
than acknowledge the receipt of a message, or it may be an ordinary system message, carrying some 

25 information, which is generated in response to an incoming system message and therefore implicitly 
acknowledges that preceding message. A system message becomes redundant when its effect is nullified 
by a later one; for example, a message requesting the setting up of a link is nullified by a later message 
requesting the cancellation of that link. 

Strictly speaking, duplicate messages are not totally ignored. When one is detected, a simple 

30 acknowledgement is sent back to the sender, though the message is not acted upon any further. This is 
because the acknowledgement of the original message may have become lost in the system; if the sender 
had received an acknowledgement for the message, the message would not be re-sent. So if an 
acknowledgement of the duplicate message was not sent, the sender might go on sending it repeatedly. If 
the sender receives an acknowledgement for a message, it can however safely delete from the resend store 

35 all messages with message numbers up to and including the message number of the acknowledged 
message, because a message can only be received, acted on, and acknowledged by the receiver if all 
preceding messages have been duly received. 

This ensures that all system messages are . acted on in the proper sequence, and the automatic 
resending each time a fresh message is generated ensures that the latest message is not delayed by 

40 resending of earlier lines. In addition, there is a second way of resending messages. If a sufficiently long 
interval passes after the sending of a message packet without the generation of a fresh message and 
without the receipt of an acknowledgement, the existing packet of stored messages in the store 95 is re- 
sent automatically. 

In preparing such a message packet, the messages are sent in exactly the same form each time. They 
45 are however re-encrypted, under the current base key. It would be possible to send the entire package as a 
unit or single message. However, it is preferred to send it in such a form that the individual messages in it 
can be acted upon as they are decrypted, so that if the message is interrupted or damaged, only part of it 
is lost, and the receiver is brought part way towards an up-to-date state. This means that the authentication 
of the package must be designed so that this can occur, while the packet is still protected from interference 
so so that an outsider cannot trick the system into responding to false messages. 

The format of a packet begins with the usual "header" information in the left-hand end of the message 
assembly register: SC, DN, MT, KN and MK sections. The contents of the MT section include an indicator 
bit indicating that the message is a packet of more than one message; the message number in the KN 
section is the message number of the current message (which will be the last in the packet). The first 
55 message of the packet is a stored message. For this, as for all the stored messages to go into the packet, 
the source and destination codes are not required, nor is a special MK required. It is therefore assembled 
as an abbreviated message, consisting of its message type MT (with the indicator bit if it is not the last of 
the stored messages), the message number KN, and the message body MB (if any). It also includes section 
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30 the retransmission can reasonably a new message does not 
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therefore duplicated, so that messages of the two classes are stored separately, block 85 comprising two 
sections A and 3 for the two classes. The messages of the higher base key (ie the base key higher in the 
hierarchy) a!! precede those of the lower base key in the packet, This means that the messages are not 
sent in strictly the same order as they were originally generated. However, the effect of this is only that 
5 some new keys may arrive slightly earlier than they would otherwise. 

The block 85 also contains a timer TMR 98, which is used to measure the time elapsed since a system 
message was last sent, and trigger a resending of unacknowledged system messages when that time 
exceeds a preset limit. This timer is reset to 0 every time a packet is sent 

The blocks 90, 91, 92, .. in each UA are included in the security module, so as to keep the list of 
w messages awaiting retransmission secure from possible outsiders. In the KDC, however, the corresponding 
blocks 85, 86, 87, ... are not included in the security module, but on backing store, for various reasons. 
Since the KDC has links with all UA's, the quantity of stored messages is likely to be much higher than for 
the UA's; the loss of the stored messages (eg- by a failure of the computer 18) is not so serious as a 
corresponding loss at a UA, since (as will be discussed later) the KDC has back-up and restore procedures; 
j$ and the KDC is less likely to be attacked by an outsider than a UA. This KDC information stored on the 
backing store is protected against corruption, either accidental or deliberate, by the local message storage 
technique described in the next section. 



20 Local Message Storage 

There are situations in which it is desirable to be able to store messages secure at a UA. Thus a user 
may want a received user message to be stored securely, either because he is not there when it is received 
or because he wants to keep it. A user may also want to securely store, in the UA, user-message-like 

25 material which he is generating. The present system provides both these facilities. 

If a received message is to be stored in the UA, it is stored in the backing store 15 in the form in which 
it was received, ie without decryption. This means that if an outsider gains access to the stored message, 
he can gain no more knowledge than he could have gained by intercepting the message on the medium 1 1, 
and in particular, he cannot gain anything by comparing the message as it appeared on medium 1 1 with the 

3o message as stored in the backing store 15. But the user must be of course able to decrypt the message for 
himself later. Accordingly, the message has appended to it the LDK under which it was encrypted. This 
LDK must itself be in encrypted form, since there are no circumstances in which keys can be allowed 
outside the security module in clear, so it is stored encrypted under the LMK above it in the key hierarchy. 
That LMK is also appended to the message, again in encrypted form, encrypted under the UMK which is at 

35 the head of the hierarchy. The UMK itself cannot be encrypted, as it is at the head of the hierarchy, nor can 
it be stored in clear as part of the message. Instead, its identification number is appended to the message 
as stored. 

It is important that keys should not appear in two different forms. Each key (apart from the UMK's) was 
received encrypted under a base key (the key above it) and a message key. The keys are stored in clear 

40 (ie after decryption) in the security module in the blocks 70, 71, 72 each key is therefor also stored in 
these blocks in the encrypted form in which it was received, along with the MK which was used for its 
encryption. When a key is appended to a message, the stored encrypted form and the associated MK are 
used to form the appendix. 

The UA contains a UMK history store UMKH 105, Fig. 4, in which the present and past UMK's are 

45 stored with their serial (identification) numbers. When a new UMK is entered into the KDC block 70, it is 
also entered into the UMKH block 105. To generate the sequence of appendices to the message, the keys 
for the various levels are in turn encrypted in the block 75, each under the key above it, and finally the 
serial number of the current UMK is taken from the register 40A (Fig. 2) in block 70. (The store 105 has a 
finite capacity, so if it becomes full, the older past UMK's are removed from it and stored in the store 15, 

so protected by being encrypted under more recent UMK's). 

To recover a stored message, the appendixes are passed one by one to the circuitry of Fig. 4, the first 
being the UMK serial number which is used to obtain the appropriate UMK from store 105, the next 
appendix being fed to the circuitry 75 for decryption under the UMK to obtain the LMK, the last appendix 
being similarly fed to the circuitry 75 for decryption under the LMK to obtain the LDK, and then the 

55 message itself being fed to the circuitry 75 for decryption under the LDK and the MK embedded in the 
message to obtain the body of the message. 

Substantially the same technique is used for secure storage of locally generated messages. A safe 
storage key block SSK 106, similar to the blocks 70, 71, 72 contains a set of key registers for the local 
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It may happen that a user wants to change from his own UA, UA1, to another UA, UA2, either 
temporarily or permanently. In the first case, he will want to be able to use the new UA temporarily to read 
messages which have been directed to his normal UA; in the second, he will want to have everything 
transferred from his old UA to his new one. These two cases are handled differently. 

For the first case, the user requests the KDC for a journey key, specifying which other terminal he. 
wants to use. The KDC thereupon issues him with a journey key, and also sets up the UA which he is 
visiting to respond to the journey key, sending the journey key (encrypted under the UMK and CDK key 
hierarchy of UA2) to UA2, where it is stored in a journey key register 107 together with the address code of 
UA1. The user also sets up his own UA to store all received messages and to respond to calls from UA2 by 
sending them to UA2. This message transfer is achieved by UA1 decrypting the message and re-encrypting 
it under the journey key (with the usual random MK), and then sending the modified message to UA2. At 
UA2, the user uses his journey key to decrypt his messages. This technique must be used with caution, as 
it involves the transmission of the same message encrypted under different keys, and also does not allow 
for updating of the journey key after a given usage. For the second case, the UMK of the user must be 
physically transported to UA2 and installed there. (In fact, all previous UMK's as well may be installed, to 
allow the transfer of securely stored messages). A link with the KDC is then established, as described 
above, and links with other UA's are then established. All stored keys already in the UA2 are of course 
destroyed before the UMK for the new user is installed, and all keys in UA1 are likewise destroyed. All 
securely stored messages in UA1 are sent to UA2 without any additional encryption, ie in their stored form 
of encrypted message plus appendices up to the UMK serial number, so that they can be decrypted at UA2 
under the newly installed UMK's. 



KDC Message Logging 

At a UA, there is no back-up system for the keys, ie for the contents of the security module. This is 
because it would be a serious weakness to have the keys available outside the security module. A failure at 
a UA can only be recovered by restarting that UA. The KDC retains a complete set of the UMK's for each 
UA, and the appropriate set can be sent to the UA over path 13 and reinstalled, so that any securely stored 
messages can be read. The UA must then be reinstalled, so that any securely stored messages can be 
read. The UA must then re-establish its links with first the KDC and then any other UA's which it wants links 
with. (As with the original setting up of UA links, much of this can be achieved by a set of stored messages 
transported over path 13 from the KDC). Any messages which were directed to it during its failed time are 
irretrievably lost; any users whose messages have been lost have the responsibility of deciding whether 
they want to resend them once the failed UA has been restored and its links re-established. 

The provisions for dealing with failures at the KDC are different. The KDC maintains a record or log of 
all messages received and sent by it in the order in which they are acted upon. This log is maintained in 
the backing store 19. Also, the state of the KDC is periodically stored in the backing store 19. If there is a 
failure at the KDC, the operator must first back up the KDC to the previously stored state, as recovered 
from the memory 19. The log of all messages which have occurred since then is then played back to the 
KDC. This brings the KDC up to its correct current state, with the exception that any keys which it 
generated and sent out during that time have been lost. Hence during the play-back of the log, any 
messages which involved the generation and sending out of keys are repeated, so sending out fresh keys 
to the UA's to replace those which were previously sent out but have become lost by the KDC. The whole 
system is thus restored to a consistent state. 



1. A messaging system comprising a plurality of terminals, in which system messages are sent 
between terminals and acknowledgements are returned, characterized in that each terminal (UA or KDC) 
stores, for each other terminal, all system messages (except simple acknowledgement messages) sent to 
that other terminal and deletes those messages from the store when acknowledgements for them are 
received, and, when the terminal has to send a fresh message to the other terminal, constructs a packet in 
which all stored messages for that terminal are included, in their correct order, in front of the fresh 
message. 
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© In a secure messaging system with several ter- 
minals 10, 10A, etc, 12 there are many system 
(control) messages, between the various terminals; 
these are* liable to deliberate or accidental change of 
sequence, deletion, duplication,, etc. To protect the 
system against this, an acknowledgement is sent for 
every message received (except a simple acknowl- 
edgement), and each station stores copies of the 
messages it has sent, deleting them only when ac- 
knowledged. When a new message is to be sent or 
a non-receipt of acknowledgement time-out occurs, a 
packet is sent with all previous messages in store 
prefixed to the new message, so the receiving sta- 
tion cannot act on the new message before receiving 
and acting on the previous messages. (There are 
known means for ignoring duplicated messages). 
Preferably there is chained serial authentication of 
the messages in the packet so that even if one is 
garbled, they can be acted on up to that point. For 
security and other reasons, user messages are in 
general not treated similarly but sent only once; with 
these, error control is a user responsibility. 
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